Re: a point is being missed
Casper Dik (casper@Holland.Sun.COM)
Mon, 6 Nov 1995 13:12:21 +0100
>(What's "static dynamic linking"?) Who's "we"? I notice you're
>sending from a sun.com address, so I assume "we" is Sun (er, SunSoft,
>whoever). In that case, "we can't do that" is just false. You (they)
>may not be willing to, but there is no reason why a libdl.a couldn't
>exist, with full functionality, mapping ld.so the first time it's
>needed.
Let me say first that I don't speak for SunSoft. This doesn't
change the fact that it is nearly impossible to do static linking
on Solaris 2.x. (And static dynamic linking is a slip of the keyboard).
I have not yet seen any good arguments against dynamic linking.
Environment variables and other environmentel tricks have always been
possible in Unix. The LD* variables have made the need for
environmental control much more obvious. su/login/sendmail didn't
do proper cleanup and passed almost any environment variable to
sub processes. That was not a problem introduced by dynamic linking.
It was a problem that had existed for a long time but that had gone largely
unnoticed. Even $TERM is dangerous in some circumstances.
>However, there is no reason why this has to be so. One option is to
>always create the dynamic-linker structures. Another is to create them
>in the presence of an option, which is documented as being necessary
>for libdl.a to work. Or perhaps ld could do it upon the presence of
>some indication in the files being linked, such as a reference to an
>undefined external called __ld_dynamic_stabs. Another way would be to
>teach ld to effectively do what ld.so does, so that it can take a .so
>file as a library even when doing a static link - and when it does so,
>have it create dynamic-linker structures in the resulting executable.
>(I've often wished for a tool that would take a dynamically linked
>a.out, chase down the .so files necessary, merge everything, and write
>out a new a.out that is effectively statically linked. I've even
>speculated about writing one, even though I really don't know enough
>about the dynamic linker at present.)
First of all: all authentication programs are extensible through dynamic
linking, all localized programs are extensible through dynamic linking,
etc. Dynamic linking is required.
Now what about libdl.a?
By putting libdl.a in a program you don't fix anything: you again have code
that searches LD_LIBRARY_PATH or even honors LD_PRELOAD.
What have you gained? You still are vulnerable to the same problems
and all you have done is spend countless man hours to make /usr/lib/ld.so
into a libdl.a (libdl.so isn't a library), changing ld, etc.
>I would argue, though, that an even better solution is to redesign the
>symbol-table mechanism. Just move the symbol table into the text
>segment and it's always available in any executable. Besides, doing
>that reduces the disk space wastage that arises in the current scheme
>from storing a symbol table in the usual a.out place and then storing
>another copy of the symbol table, in a different layout, as part of the
>executable's loaded segments. With a little care in the <a.out.h>
>macros like N_SYMOFF and N_STROFF, existing code should even work with
>this scheme, assuming it's well-behaved (basically, that it uses said
>macros and doesn't need to grow either segment).
This I agree with: there's no need to waste all that space.
>No, I'm sorry, Sun may be unwilling to go to the trouble to link login
>static (and indeed, they probably are - they've demonstrated an
>unwillingness to go to any sort of trouble for the sake of security
>until prodded by wide publicity of a problem). But claiming that
>they're unable to just doesn't hold up.
You're being unfair. Sun is pretty open about security. We publish
security patches for problems not widely know.
Besides, I don't share you opinion that linking login statically contributes
to the security of Solaris 2.x.
In Solaris 2.6, what would you rather have: a statically linked login or
a totally dynamically configurable login?
Casper